\documentclass[conference]{IEEEtran}
\usepackage{cite}
\ifCLASSINFOpdf
   \usepackage[pdftex]{graphicx}
\else
\fi
\usepackage[cmex10]{amsmath}
\usepackage{algorithm}
\usepackage{algorithmic}
\usepackage[caption=false,font=footnotesize]{subfig}
\usepackage{url}
\usepackage{color}
\usepackage{booktabs}
\usepackage{bigstrut}
\renewcommand{\baselinestretch}{1.05}
\renewcommand{\algorithmicrequire}{\textbf{Input:}}
\renewcommand{\algorithmicensure}{\textbf{Output:}}
%\addtolength{\textfloatsep}{-5mm}
\graphicspath{{../}}
%\graphicspath{{e:/wese2011/}}

%\title{Teaching Real-Time Embedded Systems using Multiple FPGA Boards}
\title{Bringing Soccer to the Field of Real-Time Embedded Systems Education}
\begin{document}
\newcommand{\todo}[1]{\textcolor{red}{[To do: #1]}}

 \author{
\IEEEauthorblockN{Akash Kumar$^{1}$, Shakith Fernando${^2}$ and Manmohan Manoharan${^3}$}
\IEEEauthorblockA{$^1$Department of Electrical \& Computer Engineering, National University of Singapore, Singapore\\
$^2$Department of Electrical Engineering, Eindhoven University of Technology, The Netherlands\\
$^3$School of Computing, National University of Singapore, Singapore\\
Corresponding Author Email: akash@nus.edu.sg}
}
\maketitle

\begin{abstract}
%\todo{Touch-up!}
With embedded systems penetrating our daily lives, there is a growing need to teach and train engineers who are well-versed in designing and developing such platforms. Owing to multi-disciplinary nature of real-time embedded systems, imparting exposure and experience in all facets of such systems is challenging. While most existing courses use a variety of hands-on projects to this end, they are usually limited to single-processor designs.

In this paper, we describe a real-time embedded systems project that is being used at the National University of Singapore. The aim of the project is to develop a 5-a-side soccer system on multiple Xilinx FPGA boards using embedded processors. Besides exposing the students to real-time concepts like scheduling, handling shared resources and priority management, the project also makes them appreciate the constraints in a typical embedded system while still making it a fun experience for them. A mini-competition is organized at the end of the project where all teams compete against each other in a knock-out tournament with 5-minute games where the progress of the game is shown on an attached VGA screen. The approach adopted in the project gives students a sense of accomplishment while reinforcing the theoretical concepts. The project has been successfully run for two terms and a similar idea has been applied in another module on embedded systems.
\end{abstract}

\section{Introduction}
\label{sec:Introduction}
Today's embedded computing platforms are fast becoming more diverse and more complex. Multi-core based mobile phones (e.g. Tegra) and hybrid net-books with FPGAs (e.g. Intel E600C) are two examples of such systems in the consumer electronics domain. Driven by Moore's law and ever reducing costs, embedded computing has further expanded from traditional application domains such as avionics and automotive industries to consumer electronics markets. This rapid proliferation is predicted to rise to 24.6 billion multi-processor based embedded systems by the year 2020~\cite{IDC}. Therefore, teaching and training engineers to design such complex and diverse embedded computing systems has become very important.

Teaching {\em embedded systems} as an integrated topic is a difficult task since it can be very diverse and multidisciplinary~\cite{Koopman:2005:UES:1086519.1086522,grimheden2005embedded,Muppala:2007:BES:1217809.1217812}. It can range from micro-controller basics and real-time concepts to hardware/software co-design, distributed processing, reconfigurable computing and system-level architecture design~\cite{jackson2005embedded}. Designing a project spanning multiple learning objectives which students can relate to is important to motivate them to acquire the skills for designing real-time embedded systems. 
%It is important to understand the balance between the various facets in order to build high-performance embedded systems. 
%The ability to understand and debug with limited documentation is %subtle, 
%difficult to convey and teach using traditional methods~\cite{Edwards:2005:ETF:1121812.1121823_WESE}.

\begin{figure}[!t]
\centering
%\includegraphics[width=3.5in]{project_setup.pdf}
\includegraphics[width=0.95\columnwidth]{images/spartan_board.jpg}
\caption{Spartan 3E Board from Digilent~\cite{digilent}}
\label{fig:board}
\end{figure}

In this paper, we describe our teaching methodology and experience in handling a real-time embedded course taught at National University of Singapore (NUS). The course includes a major design project that is carried out on a Xilinx Spartan 3E board from Digilent, shown in Figure \ref{fig:board}~\cite{digilent}. The aim of the project is to design a system for 5-a-side soccer. The system comprises of 1) a client strategy controller and 2) a server to referee and display the game in real-time. At the end of the semester, all teams compete against each other to determine the winner. The competition element motivates the students and brings the best out of them. Our distinguishing features are as follows:
%\todo{Still needs some work.}
\begin{itemize}
  \item It has a good balance of breadth (real-time concepts, multi-processor architectures and FPGA exposure) and depth (theory and implementation of real-time concepts) in teaching.
  \item It gives an opportunity for students to get hands-on experience in using hardware.
%  \item It has a good balance of theory and practical knowledge as there are assignments to teach various real-time embedded system concepts keeping the project in mind.
  \item The lab assignments are provided to help students master the complicated tool-chain and key aspects necessary for the project.
  \item It has a fun and competitive element to motivate students and enhance learning experience.
  \item It exposes students to share ideas, work in teams and manage time and resources effectively.
\end{itemize}

This paper is organized as follows. Section \ref{sec:RelatedWork} summarizes the related work on embedded systems education. Section \ref{sec:RealTimeEmbeddedCourseOverview} gives a brief overview of the real-time embedded course at NUS. Section \ref{sec:ProjectOverview} describes the project as well as the lab assignments given to students. Section \ref{sec:ProjectEvaluation} describes the evaluation criteria while highlighting some projects with innovative ideas. Feedback obtained from students is also summarized in the same section. Section \ref{sec:ConclusionsDiscussions} concludes the paper with a discussion on the insights gained from this project.

\section{Related Work}
\label{sec:RelatedWork}
%\todo{Still needs some work.}
Until early 2000s, teaching in this area was largely ignored by academics because it had not thrown up sufficient complex research challenges as pointed out by Lee~\cite{lee2000s}. Wayne Wolf et al~\cite{wolf2000embedded} were one of the first to propose a multidisciplinary approach to analysis and design of complete embedded systems. Since then, there has been a significant interest in the academic community towards formal teaching methods for embedded education as shown by the papers published in Special Issues on Embedded Systems Education in ACM Transactions on Embedded Computing Systems~\cite{Koopman:2005:UES:1086519.1086522,grimheden2005embedded} as well as the papers in the Workshop on Embedded Systems Education (WESE)~\cite{Muppala:2007:BES:1217809.1217812,jackson2005embedded,Edwards:2005:ETF:1121812.1121823,Hansson2009}. The industry has also shown interest by organizing student embedded design competitions which involve a fun and competitive element to teach embedded computing e.g. embedded design track at Microsoft Imagine Cup~\cite{mic} and Intel Undergraduate Embedded Design Contest~\cite{nuedc}.

%\todo{Grouping}
%We look at design projects for teaching real-time systems and those with multi-processor systems. As the use of FPGA as a teaching tool is extremely popular, we limit our discussion on FPGA based projects to the ones with a combination of real-time system and/or multiprocessor systems. Table \ref{tab:rw} compares different features of various design projects used for teaching.

We now compare the design projects used to teach real time embedded systems. We look at what kind of problems various design projects try to solve and their real time constraints. We also look at whether a project incorporates a uniprocessor or multi-processor system, and whether FPGA is used as a teaching tool. The features of various design projects are summarized in Table \ref{tab:rw} and explained below.

% Table generated by Excel2LaTeX from sheet 'Sheet1'
\begin{table}[t]
\setlength{\tabcolsep}{4pt}
  \centering
  \caption{Comparison of features in design projects to teach embeddeded systems}
    \begin{tabular}{|p{2.5cm}|p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|}
    \hline
    The teaching method & Does it contain a real life problem with real-time  constraints & Embed-ded Hardware & Use of Multi-processor & Use of FPGA as a teaching tool \bigstrut\\
    \hline
    McCormick {\em et al.}~\cite{mccormick2005we} & Yes  & No  & NA  & NA \bigstrut[t]\\
    Mehdi {\em et al.}~\cite{Amirijoo:2004:RMR:971300.971394} & Yes & No & NA  & NA \\
    Hansson {\em et al.}~\cite{Hansson2009} & Maybe & Yes & Yes & Yes \\
    Edwards {\em et al.}~\cite{Edwards:2005:ETF:1121812.1121823} & Proposal dependent  & Yes & NA  & Yes \\
    Previous NUS~\cite{oldee4214} & Proposal dependent & Yes & NA  & NA \bigstrut[b]\\
    \hline
    Our design project & Yes & Yes & Yes & Yes \bigstrut\\
    \hline
    \end{tabular}%
  \label{tab:rw}%
\end{table}%

%\todo{For Shakith to double check PC part.}
McCormick {\em et al.}~\cite{mccormick2005we} describe a railroad control system as a real-time project. This is a very good example of a problem with real-time constraints. The use of model trains provides a fun aspect for students. %However, as most of the control systems are implemented using PCs, the student may not get a chance of the experience in developing embedded software under constraints (e.g. memory limitations). 
Mehdi {\em et al.}~\cite{Amirijoo:2004:RMR:971300.971394} also propose a soccer system. However, their game play is run on a PC, while our project requires students to implement the system on a real embedded platform. None of the projects mentioned above focus on the usage of multi-processors or FPGAs.

Hansson {\em et al.}~\cite{Hansson2009} propose a hardware/software co-design project where students partition and map JPEG decoder on to a multi-processor platform running on an FPGA. Though it contains a good breadth of diverse aspects of designing embedded with multiprocessor, FPGA and Network-on-Chip communications, their focus is more on hardware/software co-design and the underlying architecture is static. In contrast, our project allows students to generate their custom hardware design.

Edwards {\em et al.}~\cite{Edwards:2005:ETF:1121812.1121823} share their teaching experience on embedded systems using FPGA as a teaching platform. This is a practical course where students are allowed to define their own project and implement it on hardware. Although the course does not necessarily require real-time systems, quite a few of the projects have real-time requirements (e.g. real-time video effects processor). %Multi-processor systems are not a requirement for this teaching project.

For the previous real-time embedded system design project at the National University of Singapore (NUS)~\cite{oldee4214}, students defined a real-time application and implemented it on an embedded platform. The platform provided was a Motorola uCSimm module with a MC68EZ328 Integrated Processor and RTAI uClinux operating system. Due to the complexity of the platform and limited documentation, the students spent considerable amount of project time debugging Linux and hardware issues instead of learning and implementing real-time concepts.

In our design project, we use a real-time soccer controller system as the application. This is a good example of a problem with real-time constraints to be met. Our hardware consists of multiple FPGA development boards each configured as a multi-processor system-on-chip. 

%We focus on implementing several real-time concepts using the lab assignments and the project. This project also exposes the students to the need of teamwork, time management and efficient communication as in a multi-dimensional industry project.

\section{Real-Time Embedded Course Overview}
\label{sec:RealTimeEmbeddedCourseOverview}
Real-time systems are increasingly being implemented in networked embedded devices instead of large computer systems. NUS~\cite{NUS} offers a course on real-time embedded systems with the module code {\em EE4214}. Students receive 4 modular credits for this course which translates to approximately 130 hours of work over one semester spanning over four months. The course is attended by about 80 students annually. It starts with giving an overview of the importance of making embedded systems real-time. The concepts of real-time systems like scheduling and handling shared resources are introduced. This is followed by an overview of design methodology for real-time software. Other in-depth technical topics such as concurrent programming, deadlock management, synchronization mechanisms, as well as other aspects of an embedded computer system which affect real-time performance are discussed.

The module is offered as an elective for final year undergraduate students. They are expected to be familiar with the basics of computer architecture and are expected to be comfortable with C/C++. At the end of the module, they are expected to:
\begin{itemize}
	\item be familiar with design methodologies for real-time embedded systems,
	\item understand the importance of analyzing timing behavior in embedded systems,
	\item understand the many factors affecting real-time performance in embedded systems and
	\item apply these concepts to design embedded systems with real-time performance.
\end{itemize}

The module teaches real-time concepts through a series of lectures, tutorials, lab exercises and a project. The labs and project form a very important part of the module determining 50\% of the final grade of the students. The lab exercises help them appreciate the theory that is taught in the lectures. The labs are aimed to help students gain the required knowledge and experience for the project. More details on lab exercises are provided in Section \ref{sec:ProjectFoundation}.

\section{Project Overview}
\label{sec:ProjectOverview}
The project is inspired by the Soccer World Cup. The objective of the project is to develop a 5-a-side soccer system using multiple FPGA boards. The project is carried out in groups of up to 6 students. The groups have to design the hardware architecture of the embedded system and the software for the strategy to control how to move the players in response to the position of all players and the ball. They also develop a server to communicate with the two teams and display the progress of the game on an attached VGA monitor.

The project is carried out on a Xilinx Spartan-3E FPGA board from Digilent~\cite{digilent}. The board features a Xilinx Spartan-3 1600 FPGA with about 1.6 million gates that can be reprogrammed. It also offers a number of Input/Output options to interface with other peripherals. Some of the relevant I/O ports are two serial terminals and a VGA port. The serial port is used in the project to connect with other FPGA boards while the VGA port is used to display the progress of the game on an external screen.

The project is set up as shown in Figure \ref{fig:project_setup}. As can be seen, the entire setup requires three FPGA boards -- one for the server which also referees the game and two to run heuristics from each team. The teams send updates of player movements to the server periodically. The server board processes the updates from both teams and displays the players and the ball on the attached VGA screen. Positions of the ball and players of both teams are sent back to them. Many constraints have been added to simulate real-life scenarios, e.g.\ how fast the players are allowed to run and the maximum speed of the ball. These need to be respected in the design of students. Major tasks of client and server are shown in Figure~\ref{fig:project_setup}. More details on the tasks are explained in Section \ref{sec:ProjectDetails}.

\begin{figure}[t]
\centering
%%\includegraphics[width=3.5in]{project_setup.pdf}
\includegraphics[width=3.5in]{images/project_setup.pdf}
\caption{Soccer Project Setup}
\label{fig:project_setup}
\end{figure}

\subsection{Building the Foundation}
\label{sec:ProjectFoundation}

%\todo{remove shading in the blocks}
\begin{figure*}[!t]
\centering
%%\includegraphics[width=3.5in]{project_setup.pdf}
\includegraphics[width=0.9\textwidth]{images/Visio-block.pdf}
\caption{Block diagram of the final architecture for labs}
\label{fig:block_diagram}
\end{figure*}

In this section, we describe the lab assignments that were given to students as a foundation for their project. Each lab consists of two parts: 1) the first part consists of a tutorial where step-by-step guidance is given to implement real-time concepts on multi-processor systems, 2) the second part is an assignment to allow students to use practical knowledge gained from the first part to solve a fairly simple design and implementation problem. A total of six lab assignments were provided to students as shown in Table~\ref{tab:labassignments}.

% Table generated by Excel2LaTeX from sheet 'Sheet1'
\begin{table}[t]
  \centering
  \caption{List of Lab Assignments}
    \begin{tabular}{|c|p{3.5cm}|p{3.5cm}|}
    \hline
    Lab & Topic & Relation to Project \bigstrut\\
    \hline
    1   & Familiarization of FPGA and EDK Design & Using VGA screen for the soccer game display. \bigstrut\\
    \hline
    2   & Threads & Using different scheduling algorithms to control player tasks. \bigstrut\\
    \hline
    3   & Software and Hardware Mutexes & Using shared resources like the serial communication channel between two boards in the project setup. \bigstrut\\
    \hline
    4   & Message Queues and Mailboxes & Learning inter-process communication to pass data between threads within a core and between two cores. \bigstrut\\
    \hline
    5   & Binary and Counting Semaphores & Controlling the number of active player threads on the soccer field. \bigstrut\\
    \hline
    6   & Priority Inheritance Protocol/ Priority Ceiling Protocol & Implementation of dynamic priority for cases when the priority of a thread may need to be increased to limit the blocking time of higher priority threads. \bigstrut\\
    \hline
    \end{tabular}%
  \label{tab:labassignments}%
\end{table}%

Lab-1 introduces students to Xilinx tools by implementing a Microblaze-based project on a Spartan-3E board. In this lab, they learn how to implement a single-processor system along with associated peripherals such as UART and DDR memory. They also learn to interface a VGA controller to the design and draw a moving object on the attached screen.

In Lab-2, students learn to implement a dual-processor system with additional hardware such as mutexes and mailboxes as shown in Figure~\ref{fig:block_diagram}. This complete hardware setup is designed such that the same hardware design can be used for the remaining labs. %This helps reduce development time and debugging unnecessary tool issues and help  students focus on real-time embedded software development. 
Students also learn usage of real-time OS called {\em xilkernel} and implement round robin and priority based schedulers with multiple threads.

Lab-3 allows students to experiment with both hardware and software mutexes and appreciate the relevance of each of them. The assignment involves using the dual core system to use the shared UART resource effectively between threads in the same core and in different cores.

In Lab-4 and Lab-5, students learn to implement inter-process communication and semaphores respectively. They learn to use message queues for passing messages between threads on the same processor core and use mailboxes for passing messages between threads on different processor cores. They also learn to implement binary and counting semaphores and explore their usefulness in the real-time context of the soccer game.

Lab-6 is an assignment where students are expected to implement solutions to problems caused by priority inversion. When a low priority thread has locked a certain resource which is required by a high priority thread, the high priority thread may get blocked for an unbounded period of time in presence of medium priority threads. In this lab, they learn to bound this blocking time using Priority Inheritance and Priority Ceiling Protocols.

Additionally, a guest lecturer (Assoc. Prof. Prahlad Vadakkepat), an expert on robot-soccer strategy is invited to give students a flavour of how an actual robot-soccer player system is designed. The foundation he gives on SimuroSot~\cite{simurosot} (Robot-Soccer Simulation on PC) provides students the inspiration to explore their own strategies for controlling their players.

Furthermore, weekly consultations are arranged with the teaching assistants to encourage student discussions on project from the first week itself. This not only helps them with problems using the tools and hardware, but also gives directions on the project on a weekly basis rather than at the end of semester.

For project management and dissemination of information, a wiki page is setup~\cite{wiki4214}. This is very useful to share resources such as data-sheets and detailed project specifications at one place. The wiki page also allows students to share the knowledge in solving technical problems related to hardware and EDA tools.
%FAQ page and discussion forum became very lively as it enabled the students to share 

\subsection{Project Details}
\label{sec:ProjectDetails}
As mentioned earlier, each team of up to 6 students had to develop a soccer strategy controller (also referred to as {\em client}) and a referee to display the progress of the game (also referred to as {\em server}). Both clients and the server have a number of tasks as shown in Figure~\ref{fig:project_setup}. The tasks of a client are described below.
\begin{itemize}
	\item Develop a strategy for player movements by considering the position of the ball and all players.
	\item Send initial co-ordinates for all players. This is done since in a real game the teams can determine where the players should be when the game starts.
	\item Send player movement updates. It is important to note that the client does not send the actual positions of the players during the game, as this may result in some unrealistic movements, e.g. the client may move a player from the centre of the field to near the goal instantly. The client, therefore, only sends the direction towards which the player intends to move and the speed at which the movement is desired.
	\item Receive position of the ball and players of both teams.
\end{itemize}

The server carries out the tasks that are expected of a referee and also simulates the physics of the game. Details of these tasks are provided below.
\begin{itemize}
	\item Display the game on an attached screen at 25 Hz. This refresh rate is to ensure that there is a smooth transition between frames for the viewer.
	\item Referee the game. A number of rules have to be followed for fair play. While it is not feasible to implement all of them in a virtual world with limited resources, some of them can be easily implemented, e.g.\ off-side.
	\item Receive initial player co-ordinates.
	\item Receive player movement updates from the two clients.
	\item Receive {\em kick} information from the clients. When a player is sufficiently close to the ball, it may want to kick the ball in a particular direction. This information has to be received and processed by the server.
	\item Send ball's position, speed and direction of movement.
	\item Send players' positions. Please note that the speed and direction of players is not sent by the server since that may reveal the strategy of the other team. The server only sends the information that is generally available to the other team in a real game.
	\item Simulate game physics. The physical laws have to be respected by the server as well. The most notable part that has to be followed is the conservation of momentum when a collision occurs.
\end{itemize}

\begin{figure}[t]
\centering
%%\includegraphics[width=3.5in]{project_setup.pdf}
\includegraphics[width=3.5in]{images/field.pdf}
\caption{Soccer Field Setup (not to scale).}
\label{fig:field}
\end{figure}

Figure~\ref{fig:field} shows the layout of the planned field to be displayed by the server. The VGA controller on-board supports a maximum resolution of 640x480 pixels with 3-bit colour depth. This was taken into consideration when designing the field and also the size of players and the ball. We attempted to make the relative sizes as realistic as possible. Some space was reserved for displaying score and foul information. It is interesting to note that the corners have been {\em cut-off} from the field to avoid situations when the ball may get stuck at corners.

Needless to say, that the aim of the game is to score as many goals as possible during the duration of the game. In the event that the score is equal, the winner is decided by counting the number of fouls that are committed.

The hardware setup with multiple FPGA boards allows students to explore issues that are typical in any real-time embedded system. Further, the project has a number of issues that require real-time behaviour and presents opportunities for exploring many concepts that are taught in theory. For example, the screen refresh rate is specified as 25 Hz. This implies that all computation of physics on the server and data communication, among other tasks, need to be completed within 40ms. The serial communication baud-rate is fixed at 115,200 bps; this together with the limited buffer of 16 bytes imposes strict constraints to ensure no packets are lost. The amount of memory available on the FPGA is also limited, implying that the program code cannot be very long. When students use external DDR memory, they have to be careful about resource sharing. The memory may be shared between various processors running on the same FPGA board and also the VGA controller in the case of the server. Such scenarios force students to think of many related issues in the design of a typical real-time embedded system. Figure~\ref{fig:block_diagram} shows the architecture of the dual-Microblaze design that most students use for the server.

Since each team individually develops their client and server designs, it is important to have a well-specified communication protocol to ensure that they can seamlessly communicate with the other teams. Such a well-defined protocol allows {\em plug-n-play} behaviour where we can take clients from any two teams and the server from a third one. A brief overview of the communication protocol is provided below.

\subsection*{Player to Server Communication}
\noindent Two kinds of data packets are sent from the player board to server board. At the start of a game, player boards send packets that specify the team-id, player-ids, and the initial coordinates of all players to the server. We allocated four bits for the player-id so that more players can be easily accommodated in the future versions of the project. The server does not start the game until it has received the details of players from both teams. Once the game has started, the player boards send update packets to the server board, that indicate the speed and direction of individual players of their team. Players can either move or kick the ball in any of the 16 predefined directions as shown in Figure~\ref{fig:field}. The speed of a player can have 11 values representing a range of speed from 0 to 50 pixels per second, while the speed range of the ball is larger with 16 values ranging from 0 to 100 pixels per second.

\subsection*{Server to Player communication}
\noindent The server board sends two kinds of packets to the player board viz. the update packet and the control packet. The update packets to each board contain information about the current position of players as well as of the ball. In case of a foul or a goal, the server transmits a control packet that indicates the type of event and the team responsible for the event. 

%The communication between the boards takes place through the two standard RS-232 ports available on the Spartan-3E boards. The baudrate is fixed at 115200 bps so as to avoid any performance issues due to communication bottleneck.

%\todo{The part below overlaps with earlier part. Need to see where it is more appropriate.}
%The refresh rate of 25 Hz puts a time constraint on the server of 40ms for calculating the position of ten players and the ball before updating the video frame with the new values. Additionally, the transmission of the player and positions to the client boards also had to be performed within this time constraint, thereby putting a tremendous load on the server board.

\section{Project Evaluation}
\label{sec:ProjectEvaluation}
The project determines 50\% of the final grade of students. At the end of the semester, all teams have to give a presentation detailing the following:
\begin{itemize}
	\item system design,
	\item roles and responsibilities of each member,
	\item communication details between client, server and multiple Microblazes,
	\item process description in server and team-controller and
	\item how real-time aspects are guaranteed by analysis.
\end{itemize}
The students have to justify the design choices they make in the project and appreciate their importance. A short demonstration is also expected to showcase the basic functionality, hard real-time aspects and extra features in the design.

Besides the presentation, all teams compete against each other in a knock-out fashion where each game lasts for 5 minutes. The competition proves the robustness of the system and also allows various teams to showcase their designs to the entire class. The elements of design and competition motivate the teams to work harder and bring out the best in them. Further, bonus marks are awarded to the winning teams for extra motivation.

%The approach of the groups towards implementing the system were more or less similar. Most of the groups divided the task of implementing the system into broadly three separate subtasks viz. designing the standardized communication interface, implementing a functional server system that fulfills all the tasks of server, and developing a client system that executes their strategy.

In our experience so far, students find that implementing a basic client system is quite straightforward. However, the communication interface and the server prove rather challenging. Most teams have difficulty in developing a robust communication interface using interrupts to ensure no packets were lost. For the server, the common approach taken by the groups is to develop a dual-core Microblaze system. One core is responsible for handling all the communication and calculating the positions of players and the ball while respecting the laws of physics. The second core is exclusively reserved for the task of updating the screen contents. %Using such an approach allowed the students to get hands-on experience on almost all the techniques used in developing a real-time embedded system. 
The knowledge that they gain during the lab sessions is very helpful in implementing the server system, since it uses almost all the techniques covered in the labs.

\subsection*{Example Projects}
\label{sec:ExampleProjects}
\noindent A few of the innovative features and ideas that the students have come up with during the implementation of the project are mentioned in this section. While implementing the server, only a few teams were able to meet the constraint of refreshing the screen at the required refresh rate of 25 Hz, even after allocating a separate core exclusively to deal with the screen refresh task. This issue was due to the contention occurring between the Microblaze Core and the VGA controller while accessing the video frame buffer. A part of the DDR2 off-chip memory was allocated to the VGA controller as video frame buffer. A very innovative idea was presented by one of the teams to overcome this issue. The solution adopted by the team was to have two separate video frame buffers, one for each alternate video frame. Their code swapped the pointers to the video frame buffers every alternate refresh cycle. They were able to easily achieve the required refresh rate using this approach.

Another attractive feature that was integrated by one of the teams was that of a replay system. They stored the positions of all the players and the ball in the memory for the entire history of the game and then replayed it when triggered by on-board push-buttons. They also allowed the game to be paused using a push-button. Yet another interesting feature was to allow changing run-time strategy depending on the progress of the game.

%Quite a bit was repeated..
%After the evaluation of individual groups, a mini soccer tournament is organized between all the groups to introduce the element of fun and competition. Client boards compete against each other, using a common server for the whole tournament. The best server design which is able to achieve smooth 25Hz refresh rate is chosen. The winner of a match is decided by the number of goals each team scores or by the number of fouls each team commits in case of a tie. 
A video clip of a match conducted in the tournament is available at~\cite{wiki4214}. The tournament provides an excellent platform for the groups to test the quality, robustness and interfaceability of their design.

%\begin{figure}[t]
%\centering
%\includegraphics[width=3.5in]{images/Visio-comments.pdf}
%\caption{Selected Comments on the Project}
%\label{fig:comments}
%\end{figure}

%\todo{Add more details on how we collected feedback.}

\subsection*{Feedback from Students}
The university collects feedback for all the modules taught through an on-line system. Submitting such feedback gives an incentive to the students in the form of bidding points. These points can be used by students to opt for modules of their preference. This system allows students to provide both quantitative and qualitative feedback. Further, they can optionally nominate at most 1 teacher for the best teacher award every semester.

The project was very well received by the students as indicated by both quantitative and qualitative feedback. Table~\ref{tab:feedback} shows the summary of the quantitative feedback received for the year before and after the introduction of this project. The average teacher effectiveness score (out of 5.0) increased from 4.037 to 4.242 in the year following the introduction of this project. The percentage of students nominating for the best teacher award increased from 10\% to 18\%. The qualitative feedback received from the students was also quite encouraging. Some selected comments are shown below.
\begin{quotation}
	\textit{``This module provides maximum practical exposure of the concepts learnt. Able to understand the module. The project in this module was time consuming, but gave an in-depth knowledge.''}
\end{quotation}

\begin{quotation}
	\textit{``This module is perfect. It teaches us a lot of stuff about real-time systems and the project is very fun to work on.''}
\end{quotation}

\begin{quotation}
	\textit{``This is a very interesting module because of the project.''}
\end{quotation}

\begin{table}[t]
\setlength{\tabcolsep}{10pt}
  \centering
  \caption{Quantitative feedback collected from students}
%    \begin{tabular}{|p{2.5cm}|p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|}
    \begin{tabular}{l c c}
    \hline
    Year & 2009 & 2010 \\ \hline
    Number of students & 76 & 83 \\ 
    Number of respondents & 29 & 39 \\ 
    Percentage of respondents & 38\% & 47\% \\ 
    Nominations for best teacher & 3 & 7 \\  
    Percentage of nominations & 10\% & 18\% \\ 
    Overall numerical score (out of 5) & 4.037 & 4.242 \\ \hline 
    \label{tab:feedback}
\end{tabular}
\end{table}

%An example of student comment -- ``This module provides maximum practical exposure of the concepts learnt. Able to understand the module. The project in this module was time consuming, but gave an in-depth knowledge.'' Many other students have given similar comments.

\section{Conclusions and Discussions}
\label{sec:ConclusionsDiscussions}
Teaching real-time embedded systems can be quite challenging since it spans multiple disciplines. Hands-on experiments are essential to convey the many design principles of such systems. In addition to that, projects are needed to give students a sense of achievement while reinforcing the concepts taught in the class. A real-time embedded systems project in our university is described here. The project exposes students to the concepts in a typical real-time embedded system while still making it fun for them. Sufficient foundation is provided to ease the learning curve for students.

One of the disadvantages of the project is that a number of FPGA boards are necessary since the project requires extensive use of hardware. We give 3 FPGA boards to each team so that they can easily build and test the entire system in their group. For large classes, significant investment may be necessary.

However, overall the project has been very successful. We have used a similar approach in a project in another course on Embedded Hardware System Design~\cite{wiki4218}, where students need to develop a 128-bit Advanced Encryption Standard (AES) decryptor. They are given a basic Microblaze-based system with a co-processor to do some dummy processing and display the encoded image on the attached VGA screen. The students have to implement the decryptor in software and in hardware, display the decoded image on the VGA screen and compute the speed-up due to hardware acceleration.

We sincerely hope that this description will allow faculty members of other universities to develop projects that allow students to better appreciate the constraints imposed by embedded platforms and get a good experience to work with them.

\section*{Acknowledgements}
\label{sec:Acknowledgements}
We would like to thank Xilinx University Program for their support. They donated 100 licenses for their ISE Embedded Edition, sponsored the prizes for top three teams and provided a few FPGA boards to assist in project development. We would also like to thank Prof Prahlad Vadakkepat for his inputs in how strategies are designed in autonomous robot-soccer systems. Special thanks goes to Mr Rajesh Panicker for his assistance in reviewing drafts of the paper.

%\IEEEtriggeratref{2}
\bibliographystyle{IEEEtran}
\bibliography{wese2011}
\end{document}
